На прошлом ЛАФ 2017 я рассказывал про то, как найти новую нишу в бизнесе с помощью методики Голубого океана:
http://conf.uml2.ru/class/strategiya-golubogo-okeana--kak-naiti-svoyu-nishu.html
В этот раз мы возьмем реальную компанию, пройдемся по всем шагам методики и разработаем новую стратегию развития:
1. Проанализируем текущий рынок с помощью стратегической канвы
2. Рассмотрим альтернативные рынки
3. Проанализируем схожие стратегические отрасли
4. Рассмотрим различные группы потребителей
5. Предложим дополнительные продукты и услуги
6. Посмотрим на функциональную и эмоциональную привлекательность
7. Заглянем в завтрашний день
8. Сформулируем новую стратегию компании
Длительность 1,5 часа.
С помощью UML удобно провести концептуальное проектирование, но UML не отражает мелких деталей реализации. С помощью User Story можно быстро набросать детали разработки, но при большом количестве User Story становится сложно их проверять на непротиворечивость при внесении каких-лиюбо изменений. Добавление в UML дополнения - диаграммы интерфейсов - дает возможность написать User Story как расшифровку действий проектируемых интерфейсов по описанию бизнес-процессов на диаграмме деятельности.
Использование такой технологии позволяет обеспечить:
В нашей работе много переговоров и часто это переговоры об одной и той же теме, но отличаются способами решения. Из-за простого непонимания друг-друга возникают конфликты в команде, в коллективе и с Заказчиком, которые могут привести к печальным последствиям.
Я покажу, как применить инструмент "Грозовая Туча" из набора мыслительных инструментов Теории Ограничений для подготовки к переговорам о решении.
Мастер класс рассчитан на 1,5 часа
Рассмотрим кейсы, как используя приемы психологии, языка жестов и техники вопросов, снимать негатив заказчиков во время проведения интервью и достигать поставленных целей
Рассмотрим как теоретическую так и практическую часть
Двое докладчиков.
Формат: Пести у костра
Описание:
Патрик Ленсиони, Денни Стригл, Евгений Ильин и многие другие утверждают, что основой продуктивной работы и менеджмента является доверие. Современные практики стремятся делить большие коллективы на кросс функциональные команды. Но возникает вопрос: а что такое команда, какие они бывают, из кого и когда формируются и этот список вопросов можно долго продолжать. Ведь доверие является важным фактором продуктивной коммуникации и вне коллектива или команды. По всей видимости находя разные ответы на эти вопросы мы будем определять термин «Доверие» совсем по-разному.
Управлять доверием важная составляющая работы с людьми, но для управления нужна осознанность.
В ходе свободного обсуждения предлагается рассмотреть типы команд и попробовать определить, что есть доверие и его критерии (метрики) для каждого из выделенного типа.
Центральные вопросы:
Как доверие коррелируется с лидерством.
Как измерить уровень доверия и какой уровень достаточен для функционирования и как его поддерживать.
Как доверять заинтересованным лицам и коллегам и не получить «нож в спину».
Требования, конечно, меняются. Иногда. Но гораздо чаще случается, что аналитик не до конца выдавил из заказчика и стейкхолдеров все требования, оставив множество умолчаний ("как нет этой функции? а мы думали, она будет! разве о ней нужно было отдельно говорить?")
Я расскажу и покажу техники, позволяющие задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, и обсудить нужность этих требований и их приоритеты заранее, а не при сдаче-приемке. Как правило, после применения всех техник объем требований и юзкейсов для обсуждения возрастает в 1.5-2 раза.
Возможно, многие техники вы уже применяете, а о некоторых даже не слышали; я попробую свести их в единую систему.
Вот некоторые техники (только названия!): анализ именованных сущностей, расширенные матрицы CRUD, контекстный анализ/user centered design, анализ жизненного цикла и т.д.
Каждый проект, над которым мы работаем, имеет свой уникальный язык. Именно с помощью терминов этого языка будет создаваться модель предметной области. В нем есть свои символы и соответствующие им смыслы. Нужно ли аналитику влиять на развитие этого языка? Какие сложности возникают, если не управлять процессом его формирования?
Что может быть общего у нескольких десятков аналитиков, разбросанных по проектам большой компании? Как быстрее и легче понимать другу друга при передаче требований, работая в разных командах, с разными процессами, продуктами и потребностями в компетенциях?
За год нам удалось провести ряд мероприятий в разных форматах, выявить точки взаимного непонимания и начать работать над ними, а также получить положительные отзывы коллег. Хочу поделиться опытом организации обмена опытом в отделе системного анализа и обсудить подводные камни и нерешенные вопросы этой активности.
Имеется отдел системного анализа численностью около 100 человек. Аналитики распределены по проектам компании. При этом проекты имеют совершенно разные черты, потребности, особенности и т.п.
Есть проекты продуктовые (и продукты тоже сильно отличаются по рынкам или устройствам, на которые ориентированы), есть внутренние продукты или компоненты, есть сервисы внутренние и облачные.
Все эти проекты, а значит и аналитики в их составе, так или иначе взаимодействуют друг с другом, влияют друг на друга, иногда чем-то похожи друг на друга, иногда наоборот. И очень часто не понимают друг друга в тот самый момент, когда нужно быстро договориться и что-то реализовать полезное для бизнеса.
Аналитики отдела сравнительно мало знают о том, как устроена работа у соседей, какие у них проблемы/удачи.
Мы часто по-разному понимаем одни и те же процессы или регламенты, которым должны следовать (эффект ложного консенсуса, известный в социальной психологии)
Случается, что разные проекты по-разному выстраивают схожие по сути процессы, не зная друг о друге, повторяя ошибки друг друга, изобретая велосипеды и раздражая своих общих подрядчиков, которым приходится делать одно то же разными способами в зависимости от контрагентов.
Бывает также, что, участвуя лишь в небольшом фрагменте глобального процесса, отдельному аналитику сложно понять, зачем он совершает магические действия, смысл и последствия которых от него скрыты, а значит от него трудно ожидать высокой мотивации в отношении такой задачи.
Если все это помножить на динамику происходящего:
То проблема оказывается довольно серьезной. Хотя конечно почти никогда не выглядит острой или срочной.
В отделе появилась идея заняться организацией обмена опытом в отделе. В прошлом году интерес руководства к этой теме наконец встретился с инициативой на уровне сотрудников. В результате в течение года нам удалось выработать формат, провести несколько мероприятий и сделать первые выводы.
В первую очередь мы выбирали формат мероприятия. Рассматривали варианты «электронного вестника отдела» или внутренней конференции, но отложили. Первый, потому что писем (особенно длинных) никто не читает, второй как слишком трудозатратный как для организатора, так и для докладчиков.
На мой взгляд краеугольной проблемой обмена опытом является сочетание двух противоречивых трудностей: избыток информации вокруг нас и одновременно острый ее недостаток. Естественно, избыток в большинстве случаев – это навязанный нам информационный шум, а не хватает нам всегда того, что нужно прямо здесь и сейчас для нашей текущей задачи. Мы как инициаторы пытаемся решить вторую проблему, но есть риск, что люди будут воспринимать нас как усиление первой проблемы.
Мы решили начать с регулярного проведения (1 мероприятие в 1-1,5 месяца) небольших мероприятий на 1-2 часа, каждое из которых должно быть посвящено 1 теме, и на каждое из которых будет приглашаться фокусная группа, которой данной теме интересна.
Процесс воплощения выглядел так:
В ряде случаев одной теме приходится посвящать целую серию мероприятий.
Достоинства
Трудности (недостатков пока не выявили)
Как преодолевать трудности:
Обмен опытом это: